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(57) Abstract: A database (36) is configured and information associated with a plurality of assets is stored in the database. The 
system (20) antomatically analyzes the information in accordance with a set of pre-defined conditions. When a pre-defincd condi- 
tion is met, the subsystem (28) recommends asset disposition using a hierarchy of disposition options, and the conditions and the 
options are selected to reduce expense and to maximize the return on investment for the asset user. The hierarchy of options are 
typically manually checked and confirmed, and a rejection of the hierarchy of options generates feedback with the system modifying 
as appropriate the availability of future options. 



BEST AVAILABLE COPY 



wo 03/042891 Al ililililiilliiiiiiilliMMI 



Published: 

— with international search report 

— before the expiration of the time limit for amending the 
claims and to be republished in the event of receipt of 
amendments 



For two-letter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations'* appearing at the begin- 
ning of each regular issue of the PCT Gazette. 



wo 03/042891 



PCTAJS02/36603 



SYSTEM AKD METHOD FOR DISPOSING OF ASSETS 

RELATED APPLICATIONS 
[0001) This application claims the benefit of U.S. Application 
Serial No. 09/441,289 filed November 16, 1999, U.S. 
Provisional Application Serial No. 60/166,042 filed November 
17, 1999, and U.S. Application Serial No. 09/503,671 filed 
February 14, 2000, all applications hereby incorporated by 
reference in their entirety. 

Background of the Invention 

1. Technical Field . 

[0002] The present invention relates generally to an electronic 
system and method for use in the field of asset management and 
electronic commerce. 

2. Description of the Related Art * 

[0003] The field of industrial equipment, such as forklifts, 
includes business entities at several different levels, 
including manufacturers, dealers, third-party financiers, and 

end-user customers. In one common arrangement, the dealer 

maintains an inventory of a wide variety of equipment types 
for rental to its end-user customers (i.e., the dealer's 
"rental fleet"). Some types of equipment in the dealer's 
rental fleet, however, are only infrequently needed by the 
dealer's end-user customers. Accordingly, such seldomly used 
items experience a reduced utilization rate compared to other 
items in the rental fleet. The dealer tolerates reduced 
utilization on the seldomly used items for a number of 
reasons, including maintaining customer satisfaction, and, 
hopefully, not giving the customer a reason to ''shop around" 
for a new dealer who may have larger inventory of seldomly 
used pieces of equipment. Conventional methods of conducting 

1 
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business, particularly providing rental fleets, have obvious 
shortcomings, inasmuch as the full economic value of some 
items in the dealer's rental fleet cannot be realized. 
[0004] Another common business arrangement involves a third- 
5 party financing company that buys pieces of industrial 

equipment from the manufacturer and then leases the equipment 
to the end-user customer. The customer then utilizes the 
industrial equipment (the customer's «fleet") in its business. 
In some circumstance, the customer actively "manages" the 
10 fleet of industrial equipment, attending to repair and 

maintenance, the acquisition of replacement equipment, and the 
retirement of old or unproductive equipment from the fleet. 
In other circumstances, however, the leasing company performs 
the asset management function. In either set of 
15 circumstances, challenges to be overcome by fleet managers 
include how to effectively and efficiently determine the 
timing, selection, and acquisition of replacement equipment, 
and the disposal of equipment being retired from the fleet or 
coming to an end of the lease term. 
20 [0005) Known approaches to deal with the foregoing challenges 
fall mostly into the use of manual methods. For example, 
determining whether to replace a poorly performing piece of 
equipment has typically been based on limited data relating to 
the equipment known by an experienced fleet manager. 
25 [0006] Another approach known for asset management pertains to 
passenger vehicle fleets and involves a computer-based, 
Internet-enabled vehicle selector program. The vehicle 
selector program provides average values for a plurality of 
different operating parameters and vehicle types that may be 
30 of interest to a fleet manager considering vehicle 

replacement . These parameters may include average monthly 
maintenance cost, and average miles per gallon. While the 
vehicle selector program provides at least some useful 

2 
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financial and performance information to the fleet manager, 
such a system fails to address the ultimate question fleet 
managers encounter: How does a change (i.e., an addition, or a 
subtraction) in the configuration of my fleet effect its 
5 overall performance? The known vehicle selector program 

simply does not provide information as to how a combined fleet 
would perform. 

[0007] Another challenge, particularly acute for third-party 
financing companies, involves how to effectively and 

10 efficiently dispose of assets whose lease has ended, or will 
end in the near future. Conventional analysis approaches have 
been haphazard at best. They have included utilization of 
well-known auction systems, postinig of off-lease equipment on 
electronic bulletin boards and the like for sale purposes, as 

15 well as utilization of consignment networks. One key 

shortcoming of all these known systems of disposing of end-of- 
lease assets manifests itself in the failure to fully realize 
the full, remaining economic value of the asset. One factor 
contributing to this shortcoming involves the lack of 

20 information available to potential purchasers, renters and 
lessees. Information concerning the condition, treatment, 
and, particularly, the maintenance history of the asset during 
its operating life up to the time the asset is being offered 
for disposal are all important in determining a sales price, 

25 but are frequently unavailable. In any event, such 

information is never convenient to obtain. For example, it is 
known in the passenger vehicle fleet industry to make some 
level of maintenance history data on particular vehicle 
available to the potential purchaser. However, to obtain this 

30 data, the potential purchaser must make a telephonic request 
to the asset's fleet manager, who manually looks up the 
informatipn, and provides it (e.g., by way of facsimile) to 
the potential purchaser if it is even available. Obtaining 

3 
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such information, therefore, involves a significant 
investment, both in time and effort. The investment is 
entirely lost if the purchase is not consummated, and is still 
partially lost even if the asset is finally transferred. The 
5 time lag involved in obtaining the information also leads to 
undesirable inefficiency. For example, a purchaser may have 
to make a quick decision regarding whether or not to buy a 
first asset, which would preclude a lengthy investigation of a 
second asset (e.g., the first asset may be sold by the time 

10 the investigation of the second asset has been completed) . 
This is particularly inefficient if the second asset is a 
better "fit" for the purchaser than the first asset. 
[00081 There is therefore a need for a system and method for 
facilitating transactions, and for managing assets of a fleet, 

15 that minimizes or eliminates one or more of the types problems 
exemplified above. 

STunmary of the Invention 
[0009] In one aspect of the present invention, an electronic 
system is provided for facilitating transactions, particularly 

20 rental transactions. The electronic system provides, in- 
effect, a "virtual" rental fleet available to a user of the 
system, such as a dealer. The system includes an asset 
configuration unit, a market database, a market search module, 
and a communications interface. 

25 [0010] The configuration unit is responsive to input data 
provided by a first user of the system for generating a 
profile of an asset. The asset profile comprises asset 
specification data and a bid definition. In a preferred 
embodiment the bid definition outlines parameters associated 

30 with a rental transaction of the asset. The market database 
is configured to store a plurality of asset profiles. The 
market search module is configured to search the market 
database, based on search parameters specified by a second 

4 
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user, and generate an identification of assets. The bid 
module is configured to allow the second user to select one of 
the assets on which to bid. The bid module is also adapted to 
provide rental options to the second user, based on the bid 
5 definition for the asset. Finally, the communications 

interface is configured for facilitating the electronic remote 
access by the second user of the system. , 

(00111 Through the foregoing, a dealer or the like is provided 
access to a "virtual" rental fleet of assets, some of which 

10 are not owned or controlled by the dealer. The system allows 
a . user, such as a dealer, to satisfy the requirements of the 
dealer's end-user customer without having to maintain 
infrequently used items in the dealer's own rental fleet 
(which experience low utilization rates and thus return on 

15 investment.) Additionally, the electronic system also allows a 
user, such as a dealer, who has its own under-utilized assets 
to consign such assets for rental by third parties, thereby 
allowing an increased, effective utilization rate. 
[0012] In another aspect of the present invention, an electronic 

20 system is provided for facilitating transactions, including, 
for example, assets disposal. The system, according to this 
aspect of the present invention, provides detailed information 
concerning an asset including the maintenance history data so 
that the user, a potential purchaser, rentee or lessee, may 

25 evaluate the asset. The system includes a first database, a 
market search module, and a communications interface. 
[0013] In a preferred embodiment, the first database is 
configured to store information associated with a plurality of 
assets, such as pieces of industrial equipment. The market 

30 search module is configured to search the first database, 
based on search parameters specified by the user in 
anticipation of at least one of a purchase, rental and lease 
transaction. The market search module is also adapted to 
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generate an identification of assets in accordance with the 
specified search parameters. At least one of the identified 
assets has a description that includes maintenance history 
data of the asset. The conununi cat ions interface is configured 
5 to facilitate electronic remote access of the system by the 
user, which, in one embodiment, occurs over the Internet. 
[0014) The electronic system, according to this aspect of the 
present invention, maximizes value extraction by making 
detailed information concerning the asset readily available to 
10 the user. In particular, the maintenance history of the asset 
constitutes information that may increase the price obtained 
for the asset. For example, the maintenance history data is 
particularly important to a dealer class of users of the 
system who anticipate sub-renting or sub-leasing the asset for 
15 a short term, inasmuch as a common commercial practice places 
the responsibility of maintenance on the dealer, not the end- 
user customer. Availability of information such as 
maintenance history data electronically, and immediately, 
substantially minimizes or eliminates the cost associated with 
20 information acquisition. 

[0015] In a refinement of the proposed asset disposition, a 
subsystem is disclosed, which compares a subset of all assets 
within the inventive system with a series of pre-defined 
conditions to determine if an action needs to be taken with 
25 respect to asset disposition. If a pre-defined condition is 
met, the system provides a ranked hierarchy of options based 
on the pre-defined condition that has been met. Associated 
with each option is the cost of invoking it, and the reasons 
why it is recommended for consideration. The hierarchy of 
30 options and the option determination assumptions are 

optionally reviewed and then presented to the asset user for 
cons idera t ion . 
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[0016] In another aspect of the present invention, an electronic 
system for modeling a simulated fleet is provided. The 
capability to model a simulated or ^^fantasy" fleet of assets 
provides the user with an effective and efficient mechanism to 
perform "what if" analyses. The user can then use the results 
to evaluate what effect proposed changes to an existing fleet 
would have on overall fleet performance. The electronic 
system for modeling a simulated fleet includes a simulated 
fleet configuration unit, a reporting and analysis module, and 
a communications interface. 

[00171 The simulated fleet configuration unit is provided for 
allowing a user to add a plurality of assets to the simulated 
fleet. Each asset is defined as having at least one parameter 
associated therewith. For example, in one embodiment, the 
parameter may be a total hourly cost to operate the asset. 
The reporting and analysis module is configured to generate a 
report having a composite output value that corresponds to the 
parameter, and, is characteristic of all of the assets in the 
simulated fleet. For example, the composite output value may 
be a composite total hourly cost for all the assets in the 
simulated fleet. Finally, the communications interface is 
configured to facilitate electronic remote access of the 
system by the user. For example, in a preferred embodiment, 
the communications interface allows access to the system over 
the Internet. This reduces the time and effort to obtain 
information. The system, according to this aspect of the 
present invention, provides a more effective asset management 
tool than available using conventional systems. 
[0018] In a preferred embodiment, some of the assets contained 
in the simulated fleet correspond to assets already contained 
in the user's existing fleet. . The remainder of the assets in 
the simulated fleet correspond to new or used assets proposed 
for acquisition by the user. The report generated by the 

7 
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reporting and analysis module contains a composite output 
value representative of all the assets in a simulated fleet,, 
namely, both the existing assets, and the proposed assets to 
be acquired. The report may be compared to a second report 
generated based on the performance of the assets in the 
existing fleet alone. Comparison of the two reports by the 
user allows accurate evaluation of the impact of the proposed 
changes . 

[0019] Other objects, features, and advantages of the present 
invention will become apparent to one skilled in the art from 
the following detailed description and accompanying drawings 
illustrating features of this invention by way of example, but 
not by way of limitation. 

Brief Description of the Drawings 
[0020] Figure 1 is a simplified diagrammatic and block diagram 
view of a fleet managiement and electronic commerce system in 
accordance with the present invention; 

[00211 Figure 2 is a simplified block diagram view illustrating 
functional modules according to the invention; 

[0022] Figure 3 is a simplified diagrammatic view of a screen 
output of the system of Figure 1, including a link to further 
fleet information; 

[0023] Figure 4 is a simplified diagrammatic view of a screen 
output of the system of Figure 1,. showing detailed fleet 
information; 

[00241 Figure 5 is a simplified flowchart diagram showing the 
steps for a method of adding an asset to a fleet; 
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(0025] Figure 6 is a simplified diagrammatic view of a screen 
output of the system of Figure 1, illustrating greater detail 
of a selected asset,, including maintenance history data; 

5 

[00261 Figure 7 is a simplified flowchart diagram illustrating 
the steps for a method of consigning an asset for sale, rental 
or lease; 

10 (0027] Figure 8 is a simplified diagrammatic and block diagram 
view showing, in greater detail, the process for generating 
asset specification data and a bid definition; 

[0028] Figure 9 is a simplified diagrammatic view of a screen 
15 output of a fleet search module of the present invention; 

[0029] Figure 10 is a simplified diagrammatic view of a market 
search criteria input form; 

20 [0030] Figure 11 is a simplified diagrammatic view of a screen 
output showing an identification of assets resulting from the 
market search; 

[0031] Figure 12 is a simplified diagrammatic view of a screen 
25 output showing purchase, lease and rental options; 

[0032] Figure 13 is a simplified diagrammatic view of a screen 
output showing assets contained in a simulated or '^fantasy" 
fleet; 

30 



9 



wo 03/042891 

65678-0042 (5672 DCCSP) 



PCTArS02/36603 



[0033] Figure 14 is a simplified diagrammatic view of a screen 
output illustrating a report, including a composite financial 
parameter, for a simulated fleet; 

[0034] Figure 15 is a simplified flowchart diagram illustrating 
the steps for comparing assets with pre-defined conditions and 
then providing ranked options based on the condition met with 
respect to asset disposition; and 

[0035] Figure 16 is a simplified diagrammatic view of a screen 
output illustrating a report showing the status of asset 
disposition based on available options and their 
consideration. 

Detailed Description of the Preferred Embodiments 
[0036] Referring now to the drawings wherein like reference 
numerals are used to identify identical components in the 
various views, Figure 1 is a simplified diagrammatic and block 
diagram view showing an electronic system 20 for managing, 
tracking and conducting electronic commerce, with respect to a 
plurality of assets designated 221, 22n. The assets 221, 

22n are illustrated as being a plurality of pieces of 
movable industrial equipment, such as a plurality of 
conventional forklifts or similar machinery, used in the 
manufacture of goods in a typical factory environment. It 
should be understood, however, that system 20 is configured 
for operation with a wide variety of assets. System 20 is 
further configured to manage, and facilitate commercial 
transactions involving other assets (i.e., those not tracked) 
that are consigned or otherwise made available on an 
electronic market established by system 20. 



10 
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[0037] Before proceeding to a detailed description of system 20 
keyed to the drawings, a general overview of the features of 
the present invention will be set forth, 

[0038] Electronic system 20 overcomes a problem identified in 
the Background, namely, the inability of prior systems to 
significantly facilitate business transactions that could 
increase utilization of infrequently rented assets in a user's 
rental fleet. Electronic system 20 includes functionality 
that allows users, in-effect, to consign assets on an 
electronic market in a manner that makes detailed information, 
such as maintenance history, readily available. Through the 
foregoing, users of system 20 having under- utilized equipment 
may use system 20 to '^posf such equipment on the electronic 
market for rental, lease, or the like by other users of the 
system. Not only does system 20 enable some users to increase 
utilization of under -utilized assets, other users, (e.g., 
dealers) who have an occasional need for some equipment (e.g., 
to provide to their end-user customers) , can rent or lease 
equipment from the market in contemplation of sub- rental or 
sub-lease, without having to actually own the equipment. 
Detailed information, such as maintenance history data, allow 
users to make informed decisions. Equipment selection 
efficiency is significantly improved since it is commonplace 
for users such as dealers to be responsible for the 
maintenance of equipment they sub-rent. Well-maintained and 
problem free equipment will likely be in the highest demand, 
and draw the highest lease and rental rates, 

[0039] Another shortcoming set forth in the Background involves 
the failure to realize an assets' full value upon disposal at 
the end of a lease term. Conventional systems are inefficient 
and inconvenient for making desired information available to 
new owners, lessees, and renters prior to their making 
decisions concerning such transactions. In accordance with 

11 
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the present invention, electronic system 20 is configured for 
facilitating transactions by creating an electronic market. 
In particular, system 20 is configured to allow remotely 
located users to electronically search the market based on 
search parameters they specify, and obtain a detailed 
description of the assets, including the maintenance history 
data. System 20 also includes a bidding mechanism configured 
to allow the user to bid on the assets. The contemplated 
transactions can be closed electronically. 
[00401 As stated in the Background, one shortcoming of 
conventional asset management systems involves the absence of 
an electronic '^what if" analysis tool. The present invention 
overcomes this shortcoming, enabling the creation of a 
simulated {^fantasy") fleet. A user of system 20 may add a 
plurality of assets to the simulated fleet, including 
currently held or controlled assets in an existing fleet, such 
as assets 221, 22n, as well as new and/or used assets 
available in a "market" portion of system 20. The simulated 
fleet analysis tool allows the user to evaluate proposed 
changes to an existing fleet. The tool may be used to compute 
parameters of interest that are characteristic of all the 
assets contained in the simulated fleet, which can then be 
compared to the same parameters for the user's existing fleet. 
[0041] Referring now to Figure 1, system 20 is configured for 
electronic remote access by a plurality of remote users, 
designated 231, 23n, through remote client computers 241, 
24n, over a global computer network, such as Internet 26. 
Private networks or dial-up connecting may also be used. 
Inasmuch as system 20 performs a variety of functions, such as 
tracking and management of assets, as well as facilitating 
electronic commerce, the users 231, 23n may fall into a 
plurality of user classes, which are accommodated within 
system 20. 

12 
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[0042] With continued reference to Figure 1, remote client 
computers 241, 24n may be any one of a plurality of well 
known computer systems, such as, for example, a personal 
computer (PC) running a Microsoft Windows operating system 
(e.g., Windows 95, Windows 98, Windows NT Workstation, and 
Windows 2000) , or a Macintosh computer (Apple Computer) . When 
used with Internet 26, remote client computers 241 24n are 

preferably configured to include a conventionally, 
commercially available web browser, such as, for example, 
Netscape Navigator 4.0 or higher, commercially available from 
Netscape Communications Corporation, or Microsoft Internet 
Explorer 4.0 or higher, commercially available from Microsoft 
Corporation, Redmond, Washington. The browser included on 
client computers 241, 24n preferably includes the 
capability of establishing a secure connection through 
Internet 26, by way of a firewall system 44 with web server 
30, for example, using a Secure Sockets Layer (SSL) protocol 
described below. Of course, other mechanisms for establishing 
a secure connection, such as the S-HTTP protocol may be used 
so long as both the client computers 24 and web server 30 are 
configured to include software compliant with the chosen 
protocol. Moreover, the present invention recognizes that 
different client software may be required when using private 
networks or a dial-up connection. 

[0043] System 20 interfaces with a tracking and management 
system 28, and preferably includes a first computer system, 
such as a web server 30, a second computer system, such as an 
application server 32, and a third computer system, such as a 
database server 34 . One or more of the servers may be 
combined, depending on the size and complexity of system 20. 
Database server 34 is coupled to a market database 3 6 and a 
global asset database 38 comprising a fleet database 40 and a 
preconfigured asset database 42. In the client-server 

13 
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architecture described herein, the '^server" provides the 
information to the '^clients". Electronic system 20 may 
further include, in an alternative embodiment, a firewall 
system 44 . 

5 (0044] Tracking and management system 28 is configured to 
automatically gather, analyze, and deliver information 
relating to the procurement and utilization of assets 221, 
22n, so as to maximize productivity and to reduce operating 
cost and administrative burdens. Each asset may be provided 

10 with a data acquisition device for sensing and storing one or 
more operating characteristics associated with the asset. 
Such information can be transmitted to a receiver connected to 
a collection controller contained within system 28 for 
purposes of storing such information. System 28 may be 

15 further configured to automatically update individual records 
associated with each of the assets with information received, 
including for example, maintenance history information, and 
hour-meter readings. System 28 is operatively coupled to 
electronic system 20, particularly database server 34, as 

20 shown in Figure 1. This coupling allows system 20 to be 

updated with current information regarding the tracked assets 
*221, 22n. Users 231, 23n may then access and review the 
status of their fleets, over Internet 26, using system 2 0 as a 
gateway. Tracking and management system 28 may be a system 

25 as described in co-pending application U.S. Serial No.: 

09/441,289, filed 11/16/99 entitled ^APPARATUS AND METHOD FOR 
TRACKING AND MANAGING PHYSICAL ASSETS", hereby incorporated by 
reference in its entirety, 

[00451 Web server 30 operates as a communications interface for 
30 facilitating electronic remote access of system 20 by users 
231, 23n via client computers 241, 24n when using 
Internet 26. Web server 30 is preferably compatible with the 
ubiquitous HyperText Transfer Protocol (HTTP 1.1), and 
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includes the capability of establishing a secure connection 
with client computers 241, 24n via, for example, the 
publicly available Secure Sockets Layer (SSL) protocol. 
Version 3.0 of the SSL protocol is commercially available from 
5 Netscape Communications Corporation. Web server 30 may 

comprise suitable hardware configured to handle anticipated 
traffic (e.g., requests, responses) therethrough, and may 
further execute conventional, cotwnercial software, such as 
Windows NT 4.0 operating system software running Microsoft 
10 Internet Information Server (IIS 4.0) software, both 

commercially available from Microsoft, Redmond, Washington 
USA. 

[00461 Application server 32 is configured for running 
components of system 20, described functionally below, as well 

15 as serving reports. Application server 32 may comprise 

conventional, commercially available hardware, and include 
conventional, commercially available software such as Windows 
NT 4.0 operating system software,. Microsoft Transaction Server 
2.0 transaction server software, as well as a conventional, 

20 commercially available reporting engine software, such as 
Power Builder or Crystal Reports. 

[00471 Database server 34 is configured for executing all 
database serving within electronic system 20, and may comprise 
suitably adapted hardware selected, in part, on anticipated 

25 traffic and data access response-time standards set for system 
20. Database server 34 may include conventional, commercially 
available software, such as Windows NT 4.0 operating system 
software, and Microsoft SQL server 7.0 database server 
software, both from Microsoft, Redmond, Washington USA. 

30 |0048] Web server 30, application server 32, and database server 
34 define a mult i- tiered computing environment configured to 
achieve and implement the functionality to be described in 
greater detail hereinafter. It should be \inderstood that 

15 
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alternate architectures may be employed, achieving the same 
functionality, yet remain within the spirit and scope of the 
present invention. 

[0049] System 20 organizes asset information into several 
logical groups. Market database 36, shown diagrammatically in 
Figure 1, is configured for storing a plurality of asset 
profiles, associated with a corresponding plurality of assets, 
destined for disposal on an electronic market. Contemplated 
transaction types include sale, rental and lease- The asset 
profile includes two parts: asset specification data and a bid 
definition. The asset specification data includes a variety 
of details about the asset, as well as its maintenance 
history. The bid definition outlines the parameters 
associated with the above- described commercial transactions 
contemplated for the asset. Market database 36 is illustrated 
as a logically separate database, although it should be 
understood that market database 36, in alternative 
embodiments, may be implemented together on the same physical 
hardware as the global asset database 38. Market database 36 
is configured for rapid retrieval of asset information, as 
desired to facilitate the electronic commerce functionality of 
electronic system 20. 

[0050] Fleet database 40 is conf igured to store asset 
specification data for assets contained in fleets being 
managed by system 20. As used herein, *^fleet" is a logical 
grouping or association of one or more assets, which may 
include assets 221 22n being tracked and managed by system 
28. A "fleet" may be either (i) a current fleet, or (ii) a 
simulated or ^^Fantasy" fleet. An existing fleet is a fleet 
containing assets under the control of a user, for example, 
through ownership or lease. A "Fantasy" fleet may contain (i) 
any assets in any of the user's existing fleets (*held 
assets"), (ii) new or used assets not held or controlled by 
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the user such as may be available for purchase, rental, or 
lease from third-parties via the market, or (iii) fictional 
assets having a predetermined usage, and performance profile, 
from the preconf igur ed asset database 42. 

(00511 Preconf igured asset database 42 includes a plurality of 
asset specifications for various asset types. The asset 
specification includes values that may be a composite of a 
plurality of specific, actual assets of the same or similar 
type. For example, a model «A" forklift from a particular 
manufacturer may have an average monthly maintenance cost 
based on a long history of tracking the maintenance cost for 
model forklifts. A preconf igured asset brings these 
composite values when added to a fleet. 

t0052) Firewall system 44 is disposed between the connecting 
network such as Internet 26, which is generally considered 
"insecure", and the secure, private network on which servers 
30, 32, and 34 reside and execute. Firewall system 44 may be 
implemented in software, hardware, or a combination of both. 
As is known generally, firewall system 44 is configured to 
intercept messages destined for web server 30, or exiting 
therefrom, and to examine such messages, and block those that 
do not meet security criteria. Firewall system 44 enhances 
the security, and hence the integrity, of the electronic 
market established by the invention. Firewall system 44 may 
comprise conventional devices and methodologies known to 
those of ordinary skill in the art. 

[00531 Figure 2 is a block diagram view of the functional 
modules implemented on electronic system 20. Functional 
modules include a login or authentication module 46, a fleet 
module 48 comprising a simulated fleet module 50 and a current 
fleet module 52, a fleet search module 54, a market module 56 
comprising a market search module 58 and a bid module 60, a 
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reporting and analysis module 62, and a bid definition module 
64. 

[00541 Login 46 provides authentication functions, principally 
through a user ID/password approach. In one embodiment, 
electronic system 20 includes several classes of users: a 
guest class, a member class, and a dealer class. A guest is 
characterized as having no member privileges, but can view 
assets available in market database 36, as well as other 
public areas of electronic system 20, A member has an 
enhanced set of privileges. A member may create an actual 
fleet, and/or a simulated fleet, may conduct searches of the 
assets contained in the members existing and/or simulated 
fleets, may search market database 36 and bid on selected 
assets, run reports and conduct analyses, as well as place 
assets in market database 36 for disposal. A dealer has 
access to the features available to members, but in addition, 
has access to a set of dealer tools generally unavailable to 
members, as discussed further below. Finally, electronic 
system 20 provides for an administrative class of users having 
heightened, administrative rights and privileges, for example 
to perform maintenance or reconfigure system 20. 
(00551 Before new users can practically use system 20, they must 
register. Accordingly, associated with login module 46 is a 
registration module (not shown) that allows a new user to 
register, typically as either a member, or a dealer. For 
registration activities and/or user profile changes, web 
server 30 and the corresponding client computer 24 communicate 
via a secure, encrypted connection, such as via the SSL 
encryption protocol. 

(00561 Regarding existing users, login module 46 is configured 
to automatically log the user in upon detection of an auto- 
login **cookie" . A "cookie" is a message that is given to a 
client (e.g., a web browser on a client computer 241, , 24n) 
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by a server (e.g., web server 30). Client computer 241 will 
cache the cookie, and store the cookie in a file on the client 
computer 241 if the cookie is a so-called "persistent" cookie. 
A part of the message is a description of the range of URLs 
(e.g., http://www.ironrhino.com) for which that cookie is 
valid, and a time period for which the cookie will persist. 
Any future HTTP requests by the client computer that fall 
within that URL range (e.g., http://www.ironrhino.com) and 
valid time period will include, with the HTTP request, the 
current value of the cookie to the server. In operation, 
electronic system 20 is configured to query a user 23 using a 
client computer 24 to determine whether the user wishes to 
save the user-login and password. If the user responds «YES", 
then electronic system 20, particularly web server 30, sends a 
cookie to the corresponding client computer 24, wherein the 
cookie is stored in a file. When the user subsequently 
accesses the URL from which the home page of system 20 are 
served, the browser portion of client computer 24 determines a 
match and will send the auto-login cookie, {containing 
login/password) to electronic system 20 for authentication 
purposes. Upon successful login, login module 46 directs the 
user (e.g., member or dealer) to the user's start" pa~ge "(best 
shown in Figure 3) . 

[0057 j With continued reference to Figure 2, fleet module 48 is 
configured to allow members and dealers to add their current 
fleet information into electronic system 20 for reporting, 
tracking and analyzing by module 62. It should be understood 
that such activities provide much information regarding the 
status of the fleet, and upon which important business 
decisions can be based. Simulated fleet module 50 is 
configured to allow a user 23 to access, add, view, edit and 
delete assets in a simulated fleet. According to the 
invention, the "Fantasy fleet" feature allows accurate and 
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immediate «what if analysis, unavailable through the use of 
conventional systems. Current fleet module 52 allows a member 
or dealer to access, add, view, edit, or delete assets in one 
or more existing/actual fleets associated with the registered 
member or dealer. 

[0058] Figure 3 shows a user's *'start" page 66 generated by 
fleet module 48 after a successful login. Start page 66 
includes a navigation pane, a search pane 70, a descriptive 
text pane 72, an advertising/promotions pane 74, an existing 
fleet information pane 76, and a simulated or "fantasy" fleet 
information pane 78. 

[0059] Navigation pane 68 includes, in the illustrated 
embodiment, a plurality of user-invoked (e.g., via '^clicking" 
with a mouse or other pointing device) functions or operations 
that enable efficient navigation through the various modules 
of electronic system 20. Navigation pane 68 includes a Home 
button 80, a Search button 82, a «My Fleet" button 84, a 
"Fleet Builder" button 86, a STORE button 88, a Library button 
90, a Reporting button 92, and a FAQ (Frequently Asked 
Questions) button 94. Wherever the user navigates to within 
system 20, navigation pane 68 will appear at the top of the 
screen. 

[0060] The "Home" button directs system 20 to take the user back 
to an initial login/registration page, which is then displayed 
on the user's client computer 24. Search button 82 invokes 
fleet search module 54, which is configured to search the 
user's fleets to identify assets based on user specified 
search criteria (e.g., make, model, and year of manufacture.). 
The "MY FLEET" button 84 invokes fleet module 48, taking the 
user to the user's start page 66. The "FLEET BUILDER" button 
86 invokes a fleet builder wizard to lead the user through the 
steps of creating a new fleet of actual assets, or a simulated 
fleet- The "STORE" button 88 invokes market module 56, 
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providing the user with access to conduct searches of market 
database 3 6 to identify assets for purchase, rental or lease. 
Library button 90 invokes a library module (not shown) that 
allows the user to visit the on-line library of system 20 for 
access to downloadable documents.. Reporting button 92 invokes 
reporting and analysis module 62 for obtaining reports 
containing analysis results for fleet assets or market items. 
FAQ button 94 invokes FAQ module (not shown) , allowing the 
user to access questions and answers of interest to the users 
of system 20. 

[0061] Search pane 70 includes pull down menus for defining 
search parameters for conducting a search of either market 
database 36, or fleet database 40. The search is invoked, in 
an illustrated embodiment, by selecting (i.e., ^clicking") on 
a "Search'' button 96. 

10062] The descriptive text pane 72 is configured to display 
predetermined text to the user, based on user interaction with 
electronic system 20. For example, descriptive text pane 72 
may include information instructing the user as to the 
organization of start page 66, and the available options, such 
as creating an actual fleet or a fantasy fleet . 
[00631 Advertising/promotions pane 74 is configured to display 
advertising or promotions that may be available. For example, 
certain pieces of equipment may be on a "lease special", more 
details of which may be found in the site "STORE" (i.e., via 
^'clicking" on "STORE" button 88 on the user's start page). 
(0064) Current fleet information pane 76 comprises the interface 
through which a user interacts with electronic system 20 to 
create an actual or a current fleet, and to edit or delete a 
fleet. Fleet information pane 76 includes, in the illustrated 
embodiment, a "Create Fleet" button 98, an Edit button 100, a 
Delete button 102, a radio button 104, and a link 106. 
Selecting (i.e., "clicking") on the "Create Fleet" button 98 
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causes fleet module 48 to create a new fleet record in fleet 
database 40. In one embodiment, the record includes a fleet 
name, and a location. Edit button 100, when selected by the 
user, invokes current fleet module 52, which is configured to 
allow the user to edit the fleet name and/or location of the 
fleet selected by radio button 104. Note that in Figure 3, 
only one existing fleet (i.e., the ^Denver Division") is 
illustrated; however, when two or more existing fleets are 
displayed, each have a corresponding radio button 104 
associated therewith, and only one of the radio buttons may be 
selected at a time (i.e., is darkened). The fleet having a 
darkened radio button is the ^selected" fleet for purposes of 
Edit button 100, and Delete button 102. Selecting the delete 
button 102 causes current fleet module 52 to delete the 
selected fleet from database 40. In the fleet information 
pane 76, in the illustrated embodiment, each existing fleet 
under the heading "Fleet Name" is configured to operate as a 
link to another page generated by system 20, particularly 
current fleet module 52. This "linked" page provides an . 
identification of the assets contained in the fleet. The 
portion of the "linked" page that shows the asset 
identification is illustrated in Figure 4 (portions of the 
"page" have been omitted for clarity, like the Navigation pane 
68, which has was already been shown in Figure 3) . 
[0065] With continued reference to Figure 3, Fantasy Fleet 
information pane 78 includes a "Create Fantasy Fleet" button 
108, an Edit button 110, a Delete button 112, a radio button 
114, and a link 116. Pane 78, and buttons 108, 110, 112, 114, 
and link 116 operate in a substantially identical fashion to 
pane 76, buttons 98, 100, 102, 104, and link 106, as described 
above, except that they pertain to the Fantasy Fleets. 
{0066] Figure 4 shows a screen output current fleet module 52, 
responsive to a user's selection of link 106 in Figure 3. 

22 



wo 03/042891 

65678-0042 (5672 DCCSP) 



PCTAJS02/36603 



Figure 4 includes an identification of the individual assets 
included in the **Denver Division" fleet. In an illustrated 
embodiment, the identification includes a listing of the 
following parameters for each asset: a serial number, a make, 
a model, a capacity (pounds), an asset type, an application 
rating, a usage parameter, a utilization parameter (percent) , 
and a cost /hour (U.S. Dollars). 

[00671 The view illustrated in Figure 4 includes an "Add Asset" 
button 118, an "Add Fleet Charge" button 120, an Edit button 
122, a Delete button 124, a plurality of radio buttons 126, a 
Move button 128, a pull down menu 130 including entries 1301, 
1302, 130n, and a link 132. The "Add Asset" button 118, 
when selected by the user, causes current fleet module 52 to 
add assets to the selected fleet. This process will be 
described in greater detail below. The "Add Fleet Charge" 
button 120, when selected, causes a charge (i.e., monetary 
charge) to be applied pro-rata to each of the assets included 
in the selected fleet. Edit button 122, and Delete button 
124, when selected by the user, respectively, cause current 
fleet module 52 to allow the user to edit, or delete an asset 
from the selected fleet. Which asset is affected is 
determined by which radio button 126 is selected. The edit 
function allows the user to edit the asset specification data 
associated with the asset. The "Move" button 128, when 
selected by the user, moves an asset (as selected by the radio 
button 126), from the current fleet to the fleet chosen by the 
user from one of the entries 1301, 1302, 130n in pull down 
menu which are actual fleets as well as to thereby move real, 
existing assets between existing fleets. 

[0068] Figure 5 is a simplified flowchart diagram illustrating 
the steps for a method of adding an asset to a fleet. The 
method begins in step 134. The "Add Asset" function may be 
invoked from either simulated fleet module 50 or current fleet 
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module 52. The description of Figure 5 will be made with 
reference to module 52, although it should be understood that 
module 50 could be executing the steps as well. 
[0069] In step 136, current fleet module 52 obtains basic asset 
specification data responsive to input data provided by user 
23. While the particular types of information contained in 
the asset specification data will vary depending on the 
particular asset type involved, in the illustrated embodiment 
where the asset comprises an industrial piece of equipment, 
namely a forklift, the asset specification data is divided 
into four subgroups: ^basiC, "additional" , **usage", and 
"performance". In one embodiment, the "basic" asset 
specification data may include an asset type (e.g., a standard 
forklift) , a make/model designation, a serial number, a year 
of manufacture, a capacity (e.g., in pounds), and commentary 
text. In a constructed embodiment, ^^clicking" the "Add Asset" 
button causes a dialog box to be presented to the user having 
four tabs labeled "basic", "additional", "usage" and 
"performance". The user moves from tab to tab, filling out 
respective forms, comprising input boxes and pull down menus. 
When complete, the user "clicks" on a. "SAVE" link. The method 
then proceeds to step 138. 

[0070] In step 138, module 52 obtains "additional" asset 
specification data, which in the illustrated embodiment of a 
forklift may include a mast type (e.g., quad, standard, STD,' 
TSU, etc.), a tire type (e.g., cushion, foam filled, non- 
marking, pneumatic, polyurethane, etc.), a "fuel type", a mast 
height, a tilt selection, an attachment description, an asset 
description, a condition, and an accounting system asset 
identification (ID) number, and a lease ID number. As will be 
described below, reporting and analysis module 62 generates 
reports that include financial parameters, on both a per-asset 
and a per-fleet basis (e.g., average monthly cost) . Part of 
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the cost analysis derives from how much is paid monthly to 
lease or rent the asset. This cost information, in one 
embodiment, is derived from information foiind in a separate 
accounting/leasing system (not shown) , and is identified and 
retrieved by electronic system 20 using the accounting system 
asset ID number, and lease ID number, provided as "additional" 
asset specification data in step 138. In an alternate 
embodiment, where the asset being added is not an asset 
covered under a lease in a leasing system in electronic 
communication with system 20, further financial-option 
information will be obtained from the user for the asset being 
added, which may include a purchase price (including 
applicable depreciation information so as to enable 
calculation of a monthly cost amount), a lease/rental amount, 
a lease- life rental- term, and a residual amount for 
lease/rent. The method then proceeds to step 140. 
[0071] In step 140, current fleet module 52 obtains ^*usage" 
asset specification data, which may comprise the following: an 
acquired- from name (i.e., name), an application rating (e.g., 
light, medium, heavy), a date in service, an active asset 
designation (i.e., yes or no), a number of shifts used, an 
original cost per hour, an original usage, an original 
utilization, as well as other features. The method then 
proceeds to step 142. 

[0072] In step 142, current fleet module 52 obtains 
^'performance" asset specification data comprising an original 
hour meter reading, a number of warranty months, a number of 
warranty hours, a date warranted, a date warranty removed, an 
original equipment cost, a list price, a preventative 
maintenance (PM) hours specification, and a burden labor rate. 
It should be appreciated that the original hour meter reading 
provided to system 20 in step 142 has a date associated 
therewith. The meter reading and date form a data pair. 
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Future service events on the asset will generally also include 
further meter readings, such that the fleet database will have 
a plurality of date/meter-reading data pairs, each having a 
different date attached to it, for the life of the asset. 
[0073] When the user completes the entry of the asset 
specification data, the user will be prompted to enter 
maintenance history data for the asset being configured. As 
shown in decision block 144, current fleet module 52 
determines, through a suitable prompt to the user, whether 
further maintenance history data is available. If the answer 
is *YES", then the method branches to step 146. 
(0074) In step 146, current fleet module 52 obtains the next 
item of maintenance history data for the asset being 
configured. Maintenance history data may include the job 
date, a description of the problem (e.g., work-related, abuse, 
breakdown, regular maintenance) for which maintenance was 
required, a diagnosis, a commentary, a description of the 
actual work performed, the name of the vendor performing the 
work (if applicable), whether the maintenance source is 
internal/external, whether covered under warranty, a 
description of the part replaced, a length of service, and an 
hour meter reading (usage) . Financial parameters for the 
maintenance items obtained from the user may include: Invoice 
Number, Invoice Date, Invoice Due Date, Invoice Paid Date, 
Total Cost, Labor Rate, Parts Tax, Labor Tax, Labor Hours, 
whether the item is Taxable, Exchange Rate, and Exchange Date. 
Financial parameter values for maintenance items may be used 
to determine total maintenance cost, and average maintenance 
cost for the asset. The method then loops back to decision 
element 144. If the answer to decision element 144 is «N0", 
then the method branches to step 148. 

[0075] In step 148, the asset specification data, including 
maintenance history data, for the asset being configured is 
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stored in fleet database 40. The method then proceeds to step 
150, where the "^add asset" portion of the current fleet module 
52 ends. 

[00761 The process for adding an asset to a **Fantasy Fleet", 
although not shovm specifically, is the same as outlined above 
for adding an asset to a current fleet, except that fleet 
module 48 invokes simulated fleet module 50, rather than 
current fleet module 52. 

[0077] Figure 6 shows a screen output generated by current fleet 
module 52 for a configured asset. The configured asset 
comprises asset specification data 154 including maintenance 
history data 156. In the example illustrated in the drawing, 
the user reaches the screen of Figure 6 by "clicking" on link 
132 in Figure 4. Through the foregoing, a user wishing basic 
information (i.e., a simple identification) of the assets in 
the user's fleet need proceed no further than Figure 4. 
However, for greater detail, including a description of the 
asset, the user can «drill down" by clicking on link 132 to 
reach Figure 6. Screen output 152 further illustrates an "Add 
Maintenance Item" button 158, an Edit button 160, a Delete 
button 162, a plurality of radio buttons 164 and links 166, 
and 167. 

10078] For assets being tracked and managed by way of system 28, 
maintenance history items, such as those illustrated as 
"Preventive Maintenance" and "Steering Mechanism", are 
automatically entered and available to electronic system 20 
through an information transfer, from a tracking system 28. 
For assets not tracked by system 28, such data is input to 
system 20 through "front-end" entry by the user (e.g., 
selecting the "Add Maintenance Item" button 158) . 
[0079] The Edit button 160, and the Delete button 162, when 
selected by the user, cause current fleet module 52 to allow 
the user to either edit, or delete, respectively, the 
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maintenance item selected via one of the radio buttons 164. 
The foregoing availability of asset specification data, 
including maintenance history data, enhances real time 
management of assets in a fleet (e.g., provides the ability to 
5 identify high maintenance items) . 

(0080) The user, by selecting or "clicking" on link 166, is 
provided with even greater detail for a selected maintenance 
item, for example, the item captioned ^Preventive 
Maintenance" . Selecting link 167 causes current fleet module 
10 52 to retrieve an image of the selected asset. Other features 
may be provided in the asset description shown in Figure 6, 
including links to asset specification information provided by 
the manufacturer, user manuals, repair manuals, and many other 
types of information that may be useful concerning the asset. 
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Virtual Rental Fleet 

(0081] Referring now to Figure 7, in accordance with the present 
invention, electronic system 20 is configured to facilitate 
transactions where a first user, such as a dealer, can consign 
assets, such as forklifts, to the electronic market 
established by system 20 for sale, rental, or lease. This 
feature allows the first user, such as the dealer, to increase 
asset utilization by exposure of the asset to a broader 
audience than just the end-user customers of that dealer. 
Additionally, by making assets available that a second 
user/dealer can rent, with a view towards sub-renting to an 
end-user customer, electronic system 20 in-effect provides a 
"virtual" rental fleet. The rental fleet is "virtual" because 
electronic system 20 enables the second user/dealer to provide 
equipment to his end-user customer that he does not own. 
[0082] Significantly, the availability of maintenance history 
data for an asset allows the second user/dealer to make a 
better- informed decision before renting the asset. In the 
rent/sub-rent scenario this is particularly important since 
the second user/dealer is typically responsible for the 
ongoing maintenance and service of the asset during the sub- 
rental term (i.e., the end-user customer typically does not 
pickup this responsibility during the sub-rental term) . 
[0083] Referring to Figure 7, a method of consigning an asset 
for sale, rental or lease on an electronic market includes 
several steps. These method steps will be described briefly 
as an initial matter, then in greater detail in- turn. 
[0084] Step 168 involves generating asset specification data 
including maintenance history data from input data provided by 
a first user. 
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[0085] Step 170 involves generating a bid definition from 
further input data from the first user. 

[0086) Step 172 involves storing the asset specification data 
and the bid definition together in an asset profile in market 
database 36. 

[0087] Step 174 involves searching, market database 36 based on 
criteria specified by a second user and displaying the asset 
profile. 

[00881 Step 176 involves receiving a selection of an asset from 
the second user for placement of a bid. 

[0089] Step 178 involves providing, to the second user, one or 
more of a purchase, rental or lease options, in accordance 
with the bid definition. Step 178 also includes receiving a 
bid on the asset from the second user, based on the 
transaction options. 

[0090] Step 180 involves receiving an acceptance of the bid from 
the first user. Once the bid has been accepted by the first 
user (i.e., the party "posting" the asset on the electronic 
market), bid module 60 operates to close the transaction 
contemplated by the bid. 

[0091] Figure 8 provides greater detail of generating step 168 
(producing asset specification data) and generating step 170 
(producing bid definition) . In particular, Figure 8 
graphically shows in block form an asset profile 182 
comprising asset specification data 154, and a bid definition 
184. Referring to the upper half of Figure 8, asset 
specification data 154 includes a plurality of field values, 
including maintenance history data 156. Maintenance history 
data 156, in turn, comprises at least a date parameter 186, 
and an action 188 may be any of the information referred to 
above regarding the maintenance item. In the illustrated 
embodiment, generating the asset specification data may be 
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performed by executing the "add asset" method described and 
illustrated in connection with Figure 5. 

[0092] Bid definition 184 defines the parameters associated with 
the asset being consigned for sale, rental or lease to the 
electronic market created by system 20. The bid definition 
184 defines the bounds of the sale, rental or lease 
transaction involving the asset. Bid definition module 64 
(best shown in Figure 2) is configured to generate the bid 
definition 184 as follows. In one embodiment, bid definition 
module 64, when invoked by the user, prompts the user for a 
bid date 190, an availability date 192, and information 
defining the classes of users allowed to bid on the asset 194. 
The bid date 190 establishes the date when the asset is 
available for other users to bid on. The availability date 
192 defines the date when the asset can be delivered. 
[0093) Classes of users 194 include a dealer class 196, and a 
member class 198. .With respect to dealer class 196, a logical 
variable 200 is associated therewith, and may take either of 
the values «Y", indicating that dealers are allowed to bid on 
the asset, or "N", indicating that the dealers are not allowed 
to bid on the asset. As illustrated, logical variable 200 is 
a ^'Y", indicating that dealers may bid on the asset. 
Likewise, with respect to member class 198, a logical variable 
202 is provided, and may also assume one of the values ^*Y" or 
«N" . In the illustrated embodiment, users who are in the 
member class may also bid on the asset. It should be 
understood that other logical arrangements, such as the use of 
a logical ^*0" or logical ''1" could also be used, being an 
equivalent thereof . 

(0094J Bid definition 184 also includes, for each class of 
users, an identification of which of a sale, rental, or lease 
transaction is available to that class of user. As shown in 
Figure 8, all three of a buy option 204, a lease option 206, 
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and a rental option 208 are enabled for both classes of users 
(e.g., members and dealers)- This is shown by a logical 
variable 210, (which are all set to «Y"> - For each 
transaction type available to a user class, respective 
transaction characteristic data is obtained from the first 
user. For example, the transaction characteristic data for a 
sales transaction includes a list sales price, such as shown 
in column 214, and a minimum sales price that a second user 
(e.g-, another dealer) must submit to define a valid bid, such 
as shown in column 212. The transaction characteristic data 
for a rental transaction includes a list rental price for a 
predetermined period of time (e.g., a month), and a minimum 
rental price for that predetermined period of time that the 
second user must submit in order to define a valid bid. 
Finally, the transaction characteristic data for a lease 
transaction includes a total lease amount, and a term. 
[0095] In a constructed embodiment, the bid definition module 64 
executes a bid definition wizard. The information obtained 
from the first user to populate the fields described above is 
obtained through a step-by- step process, which leads the user 
along, allowing the user to click on checkboxes to select the 
classes of users who will be allowied to bid, as well as what 
respective transactions will be available to that class of 
user. In addition, the bid definition wizard, as executed by 
bid definition module 64, allows direct entry of dates, and 
pricing, where appropriate. 

[0096] Bid definition module 64 is also configured for storing 
the asset specification data and the bid definition in an 
asset profile in a market database 36 when all the needed bid 
definition information has been collected. This is shown in 
Figure 8 by a double arrowhead line to database 36. 
[0097] Having described what bid definition 184 is, and how bid 
definition module .64 operates to obtain such information, a 
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description of the user's interaction with system 20 will now 
be set forth. To promote the greatest amount of flexibility 
for the user, electronic system 20 includes an asset 
configuration unit for preparing assets for posting and 
consignment. The asset configuration unit obtains the asset 
specification data and bid definition to form the asset 
profile, and comprises multiple interfaces/modules. These 
interfaces/modules include a create and define feature of 
market module 56, a sequence of the add-asset feature of fleet 
module 48 and the add-to-market feature of fleet search module 
54, and the add-to-market feature of fleet search module 54 
{for existing assets and shown in Figure 2) . These three 
approaches will be described in detail in- turn. 
[00981 First, in a create and define feature, the asset 
specification data (including maintenance history data) , as 
well as the bid definition are made by the first user directly 
out of market module 56. That is, when a first user, such as 
a dealer, wishes to post a piece of equipment on the 
electronic market, the first user, after logging in, initially 
selects the «STORE" button 88 (Figure 3) from the user's start 
page 66, which invokes market module 56. Market module 56, as 
one of its available functions, would directly allow 
configuration of an asset (i.e., input of asset specification 
data including maintenance history data, as v;ell as the bid 
definition) . When completed, the asset is stored in the 
market database. 

[0099] Second, if the user wishes to post an asset on the 
electronic market, but the asset does not presently 
'^electrically" exist in one of the user's fleets, then the 
user can follow the "add asset" process described above in 
connection with Figure 5. Once the asset is created 
"electrically", the user then "clicks" the "Add to Market" 
button. 
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[00100] Third, existing assets may be configured for posting 
as follows. A user, for example a dealer, who wishes to post 
the existing asset in market database 36, would invoke the 
fleet search module 54 by selecting the Search button 82. 
found on start page 66 (Figure 3). Figure 9 illustrates a 
search form that allows the user to search the user's fleets 
to identify assets based on specified search criteria. An 
identification of assets satisfying the criteria is returned 
by fleet search module 54. The user then selects the asset to 
be placed on the market. As shown in Figure 9, this selection 
is done by selecting one of the radio buttons adjacent the 
desired asset, and then "clicking" the "Add to Market" button 
215. Since the asset specification data for the selected 
asset is already stored in the fleet database 40, only bid 
definition 184 need be generated for the asset to prepare it 
for posting. "Clicking" on the "Add to Market" button 215 
invokes the bid definition wizard, described above in 
connection with Figure 8. 

(00101] Through the foregoing functionality, electronic 
system 20 allows a user, such as a dealer, to consign an asset 
to an electronic market for rental, lease, and/or sale by a 
second user, such as another dealer. This functionality 
enables the first dealer to increase utilization of 
infrequently used pieces of equipment by making those pieces 
of equipment available to a larger audience of dealers and 
end-user customers. In addition, the second dealer realizes 
an increased virtual inventory of equipment from which to, 
preferably, rent (with a view towards sub-renting to an end- 
user customer) . 

100102) In an alternative use of system 20, a non-dealer 
user of system 20, for example, an equipment leasing company, 
may purchase infrequently used equipment, for example, and 
make such equipment available through market database 36. The 
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universe of dealers (with the dealers sub-renting the 
equipment to end-user customers) and end-users may have a 
sufficiently high aggregate need for such piece of equipment 
to justify the purchase and ongoing rental to third parties. 
In this embodiment, the end-user customer need not be aware of 
the actual ownership of the equipment, and will look to the 
dealer for service, maintenance and the like. 

End-of -Lease Disposal 

[00103] A particular business type of user who may take 
particular advantage of electronic system 20 is one engaged in 
the business of financing the capital requirements of other 
companies. For example, such financing may involve the lease 
or rental of forklifts 221, 22n to the company who 
actually uses the forklifts in its business, and who pays a 
lease or rental fee. This type of user often has a large 
number of leases that may represent literally thousands of 
individual assets that are or will periodically be coming off 
of lease. Since this type of user has no direct use for such 
assets, such assets must be disposed of in an effective 
manner. The assignee of the present invention has determined 
that the information acquired during the tracking and 
management of the asset while the asset was being leased can 
be leveraged into a value proposition when such asset comes 
off of lease and must be disposed of . In particular, the 
assignee of the present invention has determined that keeping 
maintenance history data associated with assets on lease 
becomes a value-added feature when disposing of the asset in a 
fashion to be described in detail now. 

[001041 Figure 10 shows a market -search parameter input form 
216 generated by market search module 58 configured to allow a 
search of market database 36. Assets that have been tracked 
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and managed by tracking and management system 28 over an 
operating life (or portion thereof) have associated therewith 
a substantial amount of valuable information, including 
maintenance history data. When such assets come off of lease, 
the particular type of user described above (i.e., lessor) 
transfers these assets into market database 36. Each asset in 
market database 36 has an associated asset profile comprising 
both asset specification data (including maintenance history 
data) and a bid definition. Accordingly, since these end-of- 
lease assets already have the asset specification data 
defined, only a bid definition needs to be created. 
Completing the bid definition may be done manually for each 
asset, or may be automated through the use of a knowledgebase 
developed over time. Once the asset profiles for the end-of- 
lease assets are stored in market database 36, then the other 
users of electronic system 20 will be able to electronically 
search the market database, based on search parameters they 
specify, in anticipation of a purchase, rental or lease 
transaction. 

[00105] Referring to Figure 10, once such a user invokes 
market search module 58, search parameter input form 216 is 
displayed. Included in display 216 is a series of radio 
buttons: a lease radio button 218, a buy radio button 220, a 
rent radio button 222, and an ^^All" radio button 224. As 
illustrated, the lease radio button 218 has been selected; 
accordingly, all assets in market database 36 that are 
available for lease, and satisfy the other search parameters, 
will be identified and returned in an output display, shown in 
Figure 11. It should be understood that the search results 
may be further limited based on the other search parameters 
like the class of user conducting the market search (e.g., 
whether the user is a ^member" or "dealer", and whether a 
particular asset has been configured to be bid on by a 

36 



V^O 03/042891 

65678-0042 (5672 DCCSP) 



PCTAJS02/36603 



^member" or "dealer"). Selecting the "All" radio button 224 
results in a search that identifies all assets (i.e., not 
limited to any one transaction type) . Figure 10 also shows 
that a market search may be limited by a lower list price 226, 
an upper list price 228, as well as a plurality of further 
parameters, such as asset type, make/model, condition, year of 
manufacture, and availability date, as also illustrated. Once 
the user has defined the search, the market search is invoked 
by ^clicking" the Search button 230. 

[00106] Figure 11 shows a screen output 232 of market search 
module 58. Output 232 includes an identification 234 of the 
assets satisfying the search parameters. In the illustrated 
embodiment, identification 234 includes a date available 
parameter, an asset description parameter, a make and model 
parameter, a capacity parameter, a year of manufacture 
parameter, a usage rating parameter, and a status parameter. 
The status data in the status parameter column, if any, is 
indicative of whether or not the asset has been sold. As 
shown in Figure 11, status data 235 for the "Allegany Mega-8" 
asset indicates that it has been sold. Importantly, each 
asset, in an illustrated embodiment, is linked to a respective 
description, detailed in nature and which includes information 
beyond that contained in the simple identification. A user 
can "click" on the "Allegany Mega-8" wording that is 
underlined, and will be hyper-linked to its detailed 
description. Although not shown in Figure 11, the detailed 
description of an asset may be substantially identical to the 
information illustrated in Figure 6. 

[00107] Screen output 232 further includes a Bid button 236, 
a plurality of radio selection buttons 238, a "New Search" 
button 240, and an "Add to Fantasy Fleet" button 242 having an 
associated pull down menu 244. Bid module 60 is configured to 
allow the user to select one of the assets identified in the 
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market search for placement of a bid. To place a bid on an 
asset, the user first selects the asset using the radio 
buttons 238. Thereafter, the user ^clicks" on Bid button 236, 
which invokes bid module 60 . The Move or Add to fantasy fleet 
button 242 will be described in greater detail below in 
connection with the simulated fleet feature of the present 
invention. 

[001081 Figure 12 shows a screen output 245 generated by bid 
module 60. In a constructed embodiment, output 245 includes 
the detailed description of the asset, similar to Figure 6, 
but which has been omitted from Figure 12 for clarity. Bid 
module 60 provides transaction options: a purchase transaction 
option 246, a lease transaction option 248, and a rental 
transaction option 250. The desired transaction is selected 
by the user through the radio buttons. In the illustrated 
embodiment, a ^Buy" transaction has been selected by the user. 
[00109] When the selected transaction is a purchase 
transaction, bid module 60 is configured to prompt the user 
for a bid price offered for the selected asset, which is 
entered in input box 252. As used herein, the wording 
'^prompt" merely means to provide a mechanism or means to 
accept the bid price, and does not suggest or require some 
active activity, such as a blinking input box, input wizard or 
the like. 

[00110] When the selected transaction is a lease 
transaction, bid module 60 is further configured to prompt the 
user to select a lease term, a lease type, and a monthly lease 
amount offered for the selected asset. As illustrated in 
exemplary fashion in Figure 12, the lease term may be input 
through a pull down menu 254, the lease type may be input 
through pull down menu 256, and the monthly lease amount may 
be entered (e.g., keyboard) in box 258. In a constructed 
embodiment, the lease term may be one of a 24-month, 36 month, 
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48 month, 60 month, and 72 month term. Further, in a 
constructed embodiment, the lease type may be one of a 
category 1, category 2, category 3, fixed- ten (10%) percent, 
fixed-twenty percent (20%) , buyout-new, buyout-used, category 
4, category 5, category 6, and category 7 type leases. Lease 
types may be totally configurable. Of course, other options 
may be used or offered to the user, depending on the asset, 
market conditions, etc. To facilitate the bidding process, 
bid module 60 further includes a lease calculator tool, which 
may be invoked by "clicking" on the Lease Calculator button 
262. The lease calculator tool allows the user to specify 
lease term and lease type, and enter a third parameter, either 
a monthly payment or a total lease amount, and have the lease 
calculator calculate a fourth parameter, the other one of the 
lease amount and monthly payment. The calculated amount can 
be directly transferred to the monthly lease amount box 258. 
[00111] When the selected transaction is a rental 
transaction, bid module 60 is further configured to prompt the 
user for a monthly rental price offered for the selected 
asset, which may be entered in box 260. The user may submit 
the bid by ^clicking" on the "Submit Bid" button 264. 
[00112] Bid module 60 is further configured to generate a 
bid history (not shown) for each asset that has been posted in 
•market database 36. The bid history comprises a listing of 
each bid made by the users of system 20 on a particular asset. 
The bid history includes a detail of the submitted bid (e.g., 
by whom, price offered, etc.). Bid module 60 is also 
configured to allow the user that posts the asset in the 
market database (e.g., the leasing company), to retrieve the 
bid history, to review the bids contained in the listing, and 
finally to accept one of the bids to thereby complete the 
offered transaction. 
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[00113] Through the foregoing, accumulated information 
acquired from the tracking and managing of assets can be 
leveraged to increase financial return when such assets come 
off of lease and must be disposed of. 

[00114] In some cases, it is desirable to have a subsystem 
300 that runs on a periodic basis, which compares a subset of 
all assets 22 within system 20 with a series of pre-defined 
conditions 302 to determine if an action needs to be taken 
with respect to asset disposition. The pre-defined conditions 
include either a time variable or a cost variable. For 
example, one condition using a time variable involves the 
natural end of an asset lease - including, for example a set 
time period such as six (6) months prior to an end of a lease. 
Thus, the time variable is associated with the passage of 
time. A second condition using a time variable includes a 
situation such as when a particular asset has excessive usage 
compared to its time (e.g., hours) in service. An example 
condition using a cost variable involves an over usage of an 
asset, wherein based on such over usage, penalties begin to be 
invoked. Another example condition using a cost variable 
results when an analysis shows that the cost of leasing an 
asset appears to be higher than a threshold level when 
compared to other asset usage options that are immediately 
available to the asset user (e.g., a lessee) such as by 
purchasing more assets at a lower cost or reallocating 
existing assets between locations. It is also possible to 
develop pre-defined conditions using a combination of time and 
cost variables. For example, an excessive usage criteria may 
involve both a time element and a cost element. 
[00115] As illustrated in Figure 15, if no pre-defined 
conditions are met at point 302 subsystem 3 00 terminates at 
point 304. Alternatively, if a condition is met, subsystem 
300 proposes a hierarchy of options at point 306 as to a 
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proposed action for the benefit of the asset user such as a 
lessee. The data for making the various options comes from 
market database 36, global asset database 38, fleet database 
40 or asset database 42. As noted above, these may actually 
be one or more separate databases. Typically, the information 
used to determine the pre-defined conditions and available 
options comes from asset identification data, maintenance 
history data, and lease term. The identification data 
includes asset make/model and serial number. Lease term may 
be determined by an analysis of at least two of three pieces 
of data, namely, lease start date, lease end date, and the 
length of time between the lease start and end dates. 
[00116] Possible options based on pre-defined conditions 
include: the leasing of additional assets to reduce the amount 
of use of a pre-existing asset; a comparison of a cost of 
leasing an asset with a threshold level representing lower 
cost alternatives; the leasing of additional assets; asset 
lease renewal; asset purchase or buyout; asset disposal; asset 
sale; or asset sale and purchase of replacement assets. 
Associated with each option is the cost of invoking the option 
and the reasons why the system, in accordance with its review 
of each option in accordance with the pre-defined rules, 
believes that the selected hierarchy of options is preferred. 
Most often the controlling factor will be total price to the 
asset user for the collection of assets performing the same or 
similar function. 

[00117J Before suggesting lease renewal, for example, the 
system preferably reviews a database of historical information 
about lease considerations involving similar assets and 
alternatively consults with other lessor representatives to 
determine a quote for renewing the lease term. If this price 
is lower than other options, it will be listed first. 
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[00118] Before suggesting the leasing of additional assets, 
the system preferably reviews current pricing information and 
asset availability. If the system determines that the overall 
cost to the asset user will decrease the most if this option 
is selected, then it will be listed first 

[001191 In the case of buyout, subsystem 300 may review any 
existing contract language between the lessor and lessee 
concerning a fixed price. If there is no such price, it may 
then review historical information concerning buyouts 
involving similar assets potentially taking into account such 
things as asset condition and usage patterns to make a 
recommendation. 

[00120) Finally, before suggesting lease disposal, subsystem 
300 considers the cost, if any, with disposing of an asset 22, 
so that the information may be provided to the asset user. 
[001211 Once stibsystem 300 determines the hierarchy of 
possible options to send to an asset user concerning an asset 
at point 306, notification is sent to an account manager of 
the lessor having a relationship with the asset user. The 
account manager is given a report 308 that includes each asset 
meeting the pre-defined condition and a link to specific 
information about the asset including asset description, 
utilization, maintenance history and costs. If there are a 
number of assets, the assets may be grouped by asset type, 
time until lease termination, cost, usage, lessee company, 
asset location, or any other desired criteria. A group 
manager, to whom an account manager reports, may see assets 
associated with each account manager. The group manager can 
sort assets in any manner available to an account manager, but 
has the additional capability to sort assets in accordance 
with each account manager. 
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[00122] In general, the account manager will review one or 
more of the proposed options generated by subsystem 302 to 
confirm his agreement with both the hierarchy and the 
specifics of each option as shown by point 310. 
Alternatively, the account manager may just review the present 
option to confirm his agreement with the specific proposal. 
In some cases it may be desirable to bypass the account 
manager to have it sent directly to the asset user. However, 
in many cases, minor adjustments may be appropriate before the 
option details are transmitted to the asset user. Depending 
on the nature of the refinements, however, it may be desirable 
to refine the pre-defined rules in general or for a particular 
asset user if the nature of the refinement represents 
particular preferences of such a user. For example, a 
particular customer may never wish to buy an asset 22 under 
any circumstances so an option related to a buyout should 
never be presented to that customer. Thus, in a preferred 
embodiment of the invention, the proposed options are manually 
reviewed, and in the case where modifications are made, the 
rational for the modifications are incorporated back into 
subsystem 300. Thus, a rejection of a hierarchy of options 
generates feedback^ for selectively modifying the availability 
of future options by system 300 at either a global or customer 
level . 

[00123] Once the option hierarchy is finalized, the options 
are sent in descending order of expected acceptance, as 
discussed in more detail below, to an asset user by way of 
electronic mail, facsimile, regular mail, or even a link 
available on a web site accessible to the asset user. Two-way 
electronic communications with simple pre-programmed responses 
available to the asset user are preferred since no manual 
updating of subsystem 300 is then required. 
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[00124] Figure 16 illustrates an example of a report 308 in 
the form of an interactive screen available to the account 
manager or group manager with various columns. Typically, 
report 308 is accessed using a client computer 24 and web 
server 30, as discussed above. Column 312 shows a listing of 
various lessee companies. Column 314, which is broken into 
three sub- columns, relates to end of lease options. The first 
sub-column gives the months remaining before an option must be 
selected while the second sub-column gives the actual deadline 
date. The third sub-column is a hyperlink, which when 
clicked, gives detail on the various options available and 
their hierarchy, as well as specific lease related details 
such as pricing or proposed lease term. The detail can be 
optionally edited, subject to any internal lessor approval 
process. Column 316 gives facility information. Broken into 
two s\ib-columns, the first sub-column gives city and state 
information while the detail information associated with asset 
22 and its location is accessible by the hyperlink of the 
second sub- column. Column 318 includes the asset information 
in sub-column format such as asset make, model and serial 
number. More complete information including full maintenance 
history, lease information, and the like is available by way 
of the detail hyperlink. Finally, column 320 gives the status 
of various communications sent or received from an asset user. 
Communication status 320 represents the nature of all 
communications sent or received back from an asset user and 
the option currently pending from the hierarchical list of 
options available for the particular situation. A response by 
the asset user triggers automatically the next response by 
subsystem 300 for the particular asset as discussed by way of 
example below. 

[00125] In Figure 16, assets 22 are listed individually by 
each row, but also sorted by lessee company. In the present 
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example, assets 22 meeting a pre-defined condition associated 
with companies LOF and Zen's are activated for review. 
[00126) It is also possible for a specific lessee to see a 
similar screen if accessing the information by way of a client 
computer 24 and web server 30. However, in such a case, the 
information would be limited to leases associated with the 
particular lessee organization. It also facilitates follow up 
between an asset user and a lessor to avoid undesirable delay 
in determining what to do with an asset . 

[00127] If an asset user rejects a particular recommendation 
as shown by a change in communication status , the next best 
option is then presented to the account manager for review and 
transmission to an asset user until a decision is made. 
[001281 In the example of Figure 15, the option of accepting 
a new lease involving new asset is first recommended to the 
account manager at point 322. Typically, this is called '^New 
Item" in column 320. If the account manager agrees with the 
proposed terms including cost and duration, he sends it to the 
asset user. Column 320 is updated to reflect "New Item Sent". 
If the asset user accepts it ("Customer Accepts New Lease" in 
column) at point 324, then a new asset is delivered to the 
asset user at point 326, the off -leased asset is picked up at 
point 328, and the asset is moved to storage for re-sale or 
re-lease to a different party at point 330. Subsystem 300 
then forks to point 390, where system 20 is updated with the 
data related to the assets at point 392 and terminates at 
point 394. 

[00129] If the asset user rejects the new lease option 
("Customer Declines New Lease" in column 320) at decision 
point 324, then the subsystem 300 recommends based on the next 
most -favorable option, in this example that the asset user 
renews its lease of the asset ("Renew Lease" in column 320), 
which the account manager reviews in the form of an updated 
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report at point 332. If he agrees with the proposed terms 
including cost and duration, then it is sent to the asset user 
{*'Renew Lease Sent" in column 320) . If the asset user accepts 
this option ("Customer Accepts Renewal" in column 320) at 
decision point 334, then renewal documentation is sent to the 
asset user at point 336 with subsystem 300 forking to point 
390 as above. If the asset user rejects the second option 
("Customer Declines Renewal" in column 320), subsystem 300 
then suggests to the account manager that there be a buy out 
of the asset by the asset user ("Buyout"), which is reviewed 
at point 338. Once again, if the account manager agrees, the 
option with relevant detail on the terms of the proposed 
buyout is sent to the asset user ("Buyout Option Sent" in 
column 320) . If the asset user accepts that option ("Customer 
Accepts Buyout") at decision point 340 and the generated 
buyout price, then the asset is sold to the asset user as 
shown by point 342 with the subsystem forking to point 390. 
[00130] Finally, if the asset user does not accept any of 
the. prior options at point 340, then subsystem 300 sends out a 
request to the asset user concerning when the asset should be 
picked up ("Pickup Timing Sent" in column 320) at point 344, 
and the asset is picked up at the time and location agreed to 
as shown at point 346 with subsystem 300 forking to point 390. 
[00131] No interaction by the account manager is required 
once all of the remaining options have been provided. In this 
example, subsystem 300 determined that the addition of assets 
22 while maintaining the existing asset was not a viable 
option, so it was not presented for consideration. 
[00132] While Figure 15 exemplifies one possible course of 
conduct between a lessor and lessee with respect to a 
particular asset 22, the actual hierarchy of options will 
depend on the asset, characteristics of the asset user (e.g., 
e.g., a local versus a national company) current market 
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conditions (e.g., asset availability on the open market and 
pricing) , and the nature of the relationship between lessee 
and lessor (e.g., the existence of any particular preferred 
arrangement for the benefit of the asset user). Further, even 
after an asset user agrees to an option, further negotiation 
as to cost and lease timing may be required. For example, as 
shown in Figure 16, column 320 shows additional status 
entries: «New Quote Sent", *New Quote Returned" and "Quote 
Accepted", reflecting additional level of detail available as 
part of the operation of subsystem 300. 
[00133] In summary, subsystem 300 works as follows. A 
database is configured and information associated with a 
plurality of assets 22 is stored in the database. Subsystem 
300 analyzes the information in accordance with a set of pre- 
defined conditions. When a pre-defined condition is met, the 
subsystem recommends asset disposition using a hierarchy of 
disposition options, and the conditions and the options are 
selected to reduce expense and to maximize the return on 
investment for the asset user. The hierarchy of options are 
typically manually checked and confirmed, and a rejection of 
the hierarchy of options generates feedback with the system 
modifying as appropriate the availability of future options. 

Simulated (""Fantasy^O Fleet 

[00134] Conventional asset management systems lack effective 
tools for conducting ''what if" analyses i.e., modeling a 
simulated fleet containing both actual assets and proposed 
assets. The invention overcomes the shortcomings inherent in 
conventional systems by providing an electronic system 20 for 
modeling a simulated fleet. For example, if two older 
machines, each with high maintenance costs, are replaced by 
two newer machines with lower maintenance costs, but with 
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higher lease costs, what effect would such a change make on 
the overall performance of the fleet? The Fantasy Fleet 
simulator of the present invention enables computer-based 
modeling that assists answering such questions. 
(001351 As shown in Figure 3, a Fantasy Fleet may be created 
in the same manner as an actual fleet (a fleet with real 
assets) . A fantasy fleet may be created by "clicking" on a 
Create button 108, which invokes the simulated fleet module 
50, which in turn prompts the user to input a fantasy fleet 
name, as well as a location. Once the fantasy fleet has been 
created, assets may then be added. 

[00136] To promote the greatest amount of flexibility 
possible, electronic system 20, to implement the ^Fantasy" 
fleet feature, includes a simulated fleet configuration unit 
that comprises multiple interfaces/modules for setting up and 
adding assets to the fantasy fleet. These interfaces/modules 
include at least one of an add-asset feature of simulated 
fleet module 50, an add- to fleet feature via the fleet search 
module 54, an add-to-fleet feature via market search module 
58, and a step-by-step entry system of the fleet builder 
module (not shown) , accessible via the ^^Fleet Builder" button 
on the user's start page 66. Each will be described in turn. 
(00137) First, the add-asset feature of simulated fleet 
module 50 may be used. A user may "'click" on link 116 in 
Figure 3, which causes simulated fleet module 50 to generate a 
screen output 266 --an asset view-- as shown in Figure 13. 
The user interface illustrated in Figure 13 operates in 
substantially the same manner as the user interface 
illustrated in Figure 4 for assets contained in an existing 
fleet. For example, the user, by "clicking" on the "Add- 
Asset" button 268, causes simulated fleet module 50 to present 
an input data dialog, in accordance with the flowchart of 
Figure 5, for adding an asset. The user then configures the 
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asset in the same manner as described above for an existing 
fleet. 

[001381 Second, the add-to-fleet feature of fleet search 
module 54 may be used. As shown in Figure 9, a user can 
search his fleets by selecting search button 82 from the 
user's start page 66 (Figure 3), which invokes fleet search 
module 54. The search results contain an identification of 
the assets that are available for selection. Selection may 
occur, for example, through the use of radio buttons, as shown 
in Figure 9. The user may then select a destination- simulated 
fleet through the use of pull down menu 270, and then add the 
chosen asset to the desired fantasy fleet by "clicking" on Add 
button 272. 

[001391 Third, the add-to-fleet feature of market search 
module 58 may be used. The further method for adding assets 
to a fantasy fleet involves conducting a market search, using 
market search module 56, as illustrated in Figure 10. Then, 
the user adds assets by selecting the desired destination 
fantasy fleet through pull down menu 244, and "clicking" on 
the Add button 242, Through this approach, items available in 
market database 36 may be added to the fantasy fleet. 
[00140] Fourth, a user may use the fleet builder wizard to 
create a fantasy fleet and configure and add assets. The 
fleet builder wizard may be invoked by "clicking" on the 
''Fleet Builder" button 86 on the user's start page 66. This 
step-by-step entry system leads the user along, prompting for 
a fleet name, and location, an indication that it is a fantasy 
fleet, and prompts to add an asset. The add asset feature of 
the "fleet builder" dialog is substantially the same as the 
"add asset" feature of the current fleet module 52, described 
above (e.g., Figure 5). 

[00141] Figure 14 shows a report 274 generated by reporting 
and analysis module 62. In particular, each asset listed in 
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the report has an associated plurality of parameters, such as 
average monthly usage hours, total maintenance cost, hourly 
maintenance cost, total lease cost, total operating cost, 
total hourly cost, percent utilization, etc. A user can 
invoke the reporting and analysis module 62 by selecting the 
Reporting button 92 from the '^starf page 66 shovm in Figure 
3. The user may then select the target fleet (existing or 
fantasy) for which the report (s) will be generated. A user 
can evaluate changes made to an existing fleet by generating a 
report for an existing fleet, configuring a simulated fleet 
reflecting the proposed changes, and then generating a second 
report . 

[00142] The two reports can be compared and decisions made 
based on the results of the comparison. In the report shown 
in Figure 14, the assets enclosed by dashed- line box 276 are 
part of an existing fleet for which a report (not shown) has 
already been or will be generated by module 62. The assets 
shown in dashed-line box 278 are proposed additions to the 
existing fleet. The combination of the assets in dashed-line 
box 276, and dashed-line box 278 constitute the simulated or 
fantasy fleet. One exemplary parameter is total hourly cost 
280. Reporting and analysis module 62 is configured to 
generate report 274 having a composite output 282 that is 
characteristic of all the assets in the simulated fleet. The 
composite total hourly cost 282 can then be compared to the 
corresponding total hourly cost for the existing fleet (in the 
other report) to make an evaluation of the proposed changes. 
Another composite output shown in Figure 14 is percent 
utilization 284. It should be appreciated that some of the 
composite parameter values are determined by reporting and 
analyzing module 62 according to an arithmetic sum function, 
such as the total maintenance cost parameter. Reporting and 
analyzing module 62 is further configured to determine other 
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composite parameters, such as hourly maintenance cost, 
utilization, and total hourly cost, according to an arithmetic 
average function. The parameters dealing with money amounts 
(e.g., dollars) required or desirable to make an asset 
acquisition determination may be characterized as a financial 
figure of merit. Other parameters, such as utilization 
percent, may be characterized as a performance figure of 
merit . 

[00143] To the extent that the specific assets included in 
the simulated fleet have actual usage, performance, 
utilization, and cost data associated therewith, then such 
information is used by reporting and analyzing module 62 in 
computing composite values. However, when the assets are of 
the type that have no asset-specific data associated 
therewith, then profiled asset specification data is used in 
performing the analysis. Additionally, when preconf igured 
assets from preconf igured database 42 are included in a 
simulated fleet (or in an actual fleet), then composite data 
for assets of a similar type are used by module 62 for 
analysis purposes. 

[00144] In accordance with the provisions of the patent 
statutes, the principle and mode of operation of this 
invention have been explained and illustrated in several 
preferred embodiments. However, it must be understood that 
this invention may be practiced otherwise than as specifically 
explained and illustrated without departing from its spirit 
and scope. 
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CLAIMS 

What is claimed is: 

1. An electronic system for facilitating disposition of 
an asset currently under lease by an asset user, comprising: 

at least one database configured to store 
information associated with a plurality of assets; 

a set of pre-defined conditions related to a 
recommendation of asset disposition based on an automated 
analysis of said information within said system, at least one 
of said conditions being met; and 

a hierarchy of disposition options generated by said 
system based on said at least one of said conditions, wherein 
said conditions and said options are chosen to reduce expense 
by maximizing return on investment to the asset user. 

2. An electronic system as recited in claim 1, wherein 
said pre-defined conditions include at least one of a time 
variable and a cost variable. 

3. An electronic system as recited in claim 2, wherein 
said time variable comprises a passage of time, said at least 
one of said conditions being met when an asset approaches the 
end of a lease term. 

4. An electronic system as recited in claim 3, wherein 
said options include lease renewal; asset buyout; and asset 
return. 
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5. An electronic system as recited in claim 3, wherein 
said time variable comprises asset usage within a 
predetermined period of time, said at least one of said 
conditions being met when asset use exceeds a usage criteria 
based on time in service. 

6. An electronic system as recited in claim 5, wherein 
said options include the leasing of additional assets to 
reduce the amount of use of a pre-existing asset. 

7. An electronic system as recited in claim 2, wherein 
said cost variable includes a comparison of a cost of leasing 
an asset with a threshold level representing lower cost 
alternatives . 

8. An electronic system as recited in claim 7, wherein 
said options include the leasing of additional assets. 

9. An electronic system as recited in claim 1, wherein 
said information includes asset identification data, 
maintenance history data, and lease term. 

10. An electronic system as recited in claim 9, wherein 
said identification data comprises an asset make/model and 
serial number. 

11. An electronic system as recited in claim 9, wherein 
said lease term includes at least two of a lease start date, a 
lease termination date, and a length of time between said 
lease start date and said lease termination date. 
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12. An electronic system as recited in claim 1, further 
comprising a manual check and confirmation of said hierarchy 
of options, wherein a rejection of said hierarchy generates 
feedback selectively modifying said availability of future 
options by said system. 

13. An electronic system as recited in claim 1, wherein 
said options are presented to the asset user for consideration 
in order of expected acceptance. 

14. An electronic system as recited in claim 1, wherein 
one of said options is a new lease, wherein upon acceptance of 
said new lease, a new asset is delivered to the asset user, an 
off-leased asset is picked up, and said off-leased asset is 
disposed. 

15. An electronic system as recited in claim 1, wherein 
one of said options is a renewed lease, wherein upon 
acceptance of said renewed lease renewal documents are 
executed by the asset user. 

16. An electronic system as recited in claim 1, wherein 
one of said options is an asset buyout, wherein upon 
acceptance of said asset buyout, the asset is purchased . 
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17. An electronic system for facilitating disposition of 
an asset currently under lease by an asset user, comprising: 

at least one database configured to store 
information associated with a plurality of assets; 
5 a set of pre-defined conditions related to a 

recommendation of asset disposition based on an automated 
analysis of said information within said system, each of said 
conditions comprising at least one of a time variable and a 
cost variable, at least one of said conditions being met; 
10 a hierarchy of disposition options generated by said 

system based on said at least one of said conditions, wherein 
said conditions and said options are chosen to reduce expense 
by maximizing return on investment to the asset user; and 

a manual check and confirmation of said hierarchy of 
15 options, wherein a rejection of said hierarchy generates 
feedback selectively modifying said availability of future 
options by said system. 

18. An electronic system as recited in claim 17, wherein said 
20 time variable comprising a passage of time, said at least one 

of said conditions being met when an asset approaches the end 

of a lease term or when asset usage exceeds a usage criteria 

based on time in service; and 

said cost viable including a comparison of a cost of 
25 leasing an asset with a threshold . level representing lower 

cost alternatives. 
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19. An electronic system as recited in claim 17, said 
information including asset identification data, maintenance 
history data, and lease term, wherein said identification data 
comprises an asset make/model and serial number, and said 
lease term includes at least two of a lease start date, a 
lease termination date, and a length of time between said 
lease start date and said lease termination date. 

20. An electronic system as recited in claim 17, wherein 
said options are presented to the asset user for consideration 
in order of expected acceptance, and wherein, 

a first of said options comprises a new lease such that 
upon acceptance of said new lease, a new asset is delivered to 
the asset user, an off -leased asset is picked up, and said 
off-leased asset is disposed, 

a second of said options is a renewed lease such that 
upon acceptance of said renewed lease renewal documents are 
executed by the asset user, and 

a third of said options is an asset buyout such that upon 
acceptance of said asset buyout, the asset is purchased. 
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21. A method for facilitating disposition of an asset 
currently under lease an asset user, comprising the steps of: 

configuring at least one database and storing 
information associated with a plurality of assets; 
5 analyzing said information in accordance with a set 

of pre-defined conditions, each of said conditions comprising 
at least one of a time variable and a cost variables- 
meeting at least one of said pre-defined conditions; 
recommending asset disposition using a hierarchy of 
10 disposition options; and 

selecting said conditions and said options by 
reducing expense and maximizing return on investment to the 
asset user. 

15 22. A method as recited in claim 21, further 

comprising the step of: 

instituting a manual check and confirmation of said 
hierarchy of options; and 

said rejection of said hierarchy generating 
20 feedback, selectively modifying said availability of future 
options by said system. 
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23. An electronic system as recited in claim 21, 
including the further step presenting said hierarchy of 
options to the asset user for consideration in order of 
expected acceptance, and wherein, 

a first of said options comprises a new lease such that 
upon accepting said new lease, delivering a new asset to the 
asset user and picking up and disposing of an off -leased 
asset, 

a second of said options is a renewed lease such that 
upon accepting said renewed lease renewal, the asset user 
executing renewal documents, and 

a third of said options is an asset buyout such that upon 
accepting said asset buyout, the asset user purchases the 
asset. 
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